The RLC layer in 3GPP can operate in three modes, transparent mode, unacknowledged mode and acknowledged mode (AM), which will be focused upon in the following.
In AM mode, incorrectly received PDU's (Protocol Data Units) discovered by the receiving side are effected to be retransmitted by the transmitting side by means of an ARQ (Automatic Repeat Request) protocol.
An AM RLC entity consists of a transmitting side, and a receiving side, where the transmitting side of the AM RLC entity transmits RLC PDU's and the receiving side of the AM RLC entity receives RLC PDU's.
An AM RLC entity resides in the UE (user equipment) and in the RNC (radio network control), respectively. The transmitting side segments and/or concatenates RLC SDU's (service data units) into PDU's of a fixed length. The receiving side reassembles received PDU's into RLC SDU's and transmits these to higher data layers. Likewise, SDU's are received from the layer above the RLC layer. In AM mode, the RLC layer is responsible for the delivery of SDU's in consecutive order.
In FIG. 4 of document WO2005/034418, an implementation of the acknowledged mode (AM) UE (base station)/UTRAN (Radio access node/base station (Node B)) entity is shown.
To facilitate the in-sequence delivery, each RLC PDU is given a sequence number, 0-4095, whereby the transmitter transmits PDU's with increasing sequence number modulo 4096. Using the sequence number, the receiver can detect a missing PDU. The receiver can be configured to transmit a STATUS message upon the detection of a missing PDU. The STATUS report may contain positive or negative acknowledgement of individual RLC PDU's received by the peer RLC entity. The transmitter can also request a STATUS messages from the receiver by setting a Poll flag in the PDU header. The conditions for that the transmitter sets the Poll flag are among others:                Last PDU in buffer. When only one PDU exists in the input buffer, the poll flag is set.        Poll timer expires. When a parameter timer_poll expires, that is, the transmitter requested a STATUS earlier and initiated a timer_poll to reassure that a response is received.        Window based. A transmitter is restricted in the amount of “outstanding data” it can transmit until a STATUS confirms the reception to the receiving side. “Outstanding data” relates to the earliest unacknowledged PDU.        
Note that the above description of the functionality of the RLC layer only constitutes a small excerpt of those features actually provided.
Selective retransmissions are possible, e.g. if STATUS message indicates PDU with sequence number (SN) 3, 6 and 13 are missing, only 3, 6 and 13 needs to be retransmitted.
To recover from erroneous conditions when MAC-hs PDU's are missing, various stall avoidance mechanisms as described in 3GPP TS 25.321-11.6.2 (re-ordering release timer and window based stall avoidance) are used.
Handover
In HSDPA there exists only one Node-B at a time which transmits data to the UE. The Node-B will buffer received MAC-d PDU's from the RNC and an internal scheduler will determine when to transmit these MAC-d PDU's in MAC-hs PDU's to the UE. The UE will receive data at its MAC-hs receiver and deliver data to corresponding higher layer applications.
At a time of a handover between one Node-B and another Node-B, there may exist MAC-d PDU's which have been sent from the RNC RLC layer but which have not been received at the UE RLC layer yet. This may be due to one or more of the following circumstances:                MAC-d PDU's transmitted from the RNC RLC layer are pending (or buffered) in Node-B and have subsequently not been transmitted from Node-B yet;        MAC-d PDU's transmitted from the RNC RLC layer may have been sent from Node-B (as MAC-hs packet data units) but have not been properly received at the UE yet; or        MAC-d PDU's transmitted from the RNC RLC layer may have been properly received at the UE (as MAC-hs packet data units) but due to the MAC-hs protocol reordering mechanism, these PDU's have not been delivered to the UE RLC layer yet.        
In the following, we shall briefly refer to the above three situations as MAC-d PDU's having been discarded in Node B.
If a handover occurs, the MAC-d PDU's described above will be deleted (or lost), and the RLC layer of the RNC will have to retransmit the data in order to avoid loss of e.g. TCP data.
In prior art document ‘System for efficient recovery of Node B buffered data following serving high speed downlink shared channel cell change’, US 2004/0165554, it is described how a UE experiencing a cell change sends a PDU STATUS message autonomously to the RNC, whereby the RNC more rapidly can retransmit MAC-d PDU's that have not been received at the UE.
A new Medium Access Control entity MAC-ehs has been introduced in 3GPP rel 7. MAC-ehs can be used alternatively for MAC-hs. MAC-ehs supports flexible RLC MAC-d PDU sizes as well as MAC segmentation/reassembly. Furthermore, unlike MAC-hs for HSDPA, MAC-ehs allows to multiplex data from several priority queues within one transmission time interval of 2 ms.
In the invention descriptions is made referring to MAC-hs unless specifically mentioned. It will however be appreciated that MAC-ehs can be used similarly.
For further information about HSDPA see: http://www.ericsson.com/solutions/tems/articles/Q4—2005_High_Speed_Downlink_Packet_Access_part1.pdf
For information about MAC-ehs see: http://www.ericsson.com/ericsson/corpinfo/publications/review/2008—01/files/5_HSPA_Evolution.pdf
For information about EUL see: http://www.ericsson.com/technology/research_papers/wireless_access/doc/wcdma_enhanced_uplink_principles_and_basic.pdf
All documents being publicly available on the official Ericsson web site www.ericsson.com on 20081230.
The following picture shows the signalling between the RNC and Node-B at cell change:
Problems With Existing Solutions
In prior art document US 2004/0165554 (see section [0011]), a description is first made of the known prior art mechanism, which is following the HS-DSCH cell change:    1) the RNC can explicitly request a status PDU from the UE);or    2) the RNC can just start transmitting where it stopped in the source cell and out-of-sequence delivery realized by the UE will generate the status PDU.
As described in US 2004/0165554, the recovery can be considerably delayed and it is noted that delays and delay jitter are negative for end user TCP performance. Prior art US 2004/0165554 further continues proposing a mechanism to mitigate the negative effects on end-user throughput, caused by the recovery due to delays and delay jitter, where the UE upon a cell change autonomously transmits a Status PDU to the serving RNC. At the reception of the Status PDU, the RNC will discover which data that is lost and perform the retransmission faster than for 1) and 2) above.
Let us now focus on the delivery time for the autonomous Status PDU and compare this against the total time it takes until the UE receives the missing PDU's. Let us first start to estimate the delay until it takes to transmit the Status PDU to the RNC. We assume that the user is using HS-DSCH for downlink transmissions and E-DCH for the uplink:
Case 1—An EUL grant exist for the UE (best case)
(Assume an E-DCH configuration with TTI=10 ms)
First we assume that the waiting time from that the Status PDU, generated from the RLC layer at the UE, is received at the UE EUL layer until it is transmitted in the E-DPDCH TTI is 5 ms. I.e. half the TTI interval.
Transmission time is equal to the TTI period, 10 ms.
Propagation delay is considered to be low compared to the other time delay component. Decoding time at Node-B until transmitted at the lub interface between 5-10 ms. Total delay until transmission on lub is estimated to be between 20-25 ms.
Case 2—No EUL Grant Exists for the UE (Worst Case)
When EUL entity in the UE receives the Status PDU, generated from the RLC layer at the UE, the UE has to signal up to the Node B that a transmission is required, e.g. to transmit unhappy on E-DPCCH, in order to force Node B to grant a transmission for the UE via AGCH.
FIG. 3 illustrates the problem:    1) Data is received from the RLC layer (i.e. Status PDU)    2) A scheduling information is sent as part of the MAC-e header.    3) The scheduler in Node-B receives the scheduling information.    4) A Grant is sent to the UE, signalling the ability to transmit.
A rough estimate gives that steps 1)-4) will take in the range between 30-100 ms, for a configuration with TTI=10 ms.
If we now compare case 1 and case 2 delays with the remaining delay components:    a) The transmission of the Status PDU up to the RNC's RLC layer on lub.    b) The reaction time for RNC's RLC layer to retransmit MAC-d PDU's    c) Delivery time to Node-B on lub for the retransmitted PDU's.    d) Waiting time in Node-B until first transmission occurs on MAC-hs.    e) Data reception on MAC-hs UE and transmission from UE MAC-hs layer to RLC layer            a) and c)is assumed to be small in the range <1 ms or <<1 ms.        b) depends upon the load in the RNC, but an estimate is approx 1 ms.        d) is assumed to be in the range 3-5 ms.        e) if we assume that the retransmitted MAC-d PDU's all fit into one MAC-hs PDU and that first transmission are successful, then the additional delay is assumed to be in the range 0.5 to 3 ms. If a retransmission is needed, then the delay will be in the range 12.5-15 ms. If a 2nd retransmission is needed: 24.5-27 ms.        
All in all the remaining delay is assumed to be:    No Node-B retransmission: 6-10 ms.    1 Node-B retransmission: 18-22 ms.    2 Node-B retransmissions: 30-34 ms.
All in all, we can conclude that the initial delay estimation—either 20-25 (case 1) or 30-100 ms (case 2)—above can be considerably longer than the remaining delay above, or at least comparable with the remaining delay.